| 长轮询（long polling） | Webhook | |
|---|---|---|
| 简述 | 利用 API 中的 getUpdates 方法， 如果 Bot 上次标记完成后没有收到信息，或消息已保存超过24小时，该方法会保持等待直到超时，在等待期间收到信息将会立刻返回结果；反之，该方法会返回一组包含了24小时内所有未标记信息的 Updates。利用 offset 参数可以将部分消息标记为已处理。 | 利用 setWebhook 方法告知服务器一个 url， 服务器将会在收到新消息时，通过 POST 方法将 json 格式的 Update 对象发送到指定的 url 地址。如果发送失败，Telegram 会重试一定次数。这个 url 必须是 https 的。 |
| 性能 | 没法做负载均衡，数据量比较大的情况话，性能瓶颈可能出现在 worker 上。 | 与传统服务器没有太大差异，可以做负载均衡（高可用），可以横向扩展。未来可以对接 Serverless，可扩展性更强 |
| 开发效率 | 不需要搭建服务器，不需要处理 https 证书，有一个机器人的 token 就可以在本地开发 | 在不搭建服务器的情况下，可以用 google script 开发，但只能用类 Javascript 语言。如果要用其他语言开发，需搭建服务器，需 https |
| 交互体验 | 响应速度较 Webhook 慢 | 响应速度取决于网络延迟，体验一般比长轮询好 |
结论：如果追求开发速度，并且不需要考虑服务的高可用性，在可预知用户量不会增长过快的情况下，建议使用长轮询的方式，未来用户增长比较多再改也来得及，否则用 Webhook 的方式。如果对交互体验要求高的话，最好采用 Webhook 的方式。